but means we still need _has_dynamic_options, which is marked as a hack in plugins/base.py.

It's OK for me, in long-term it's a candidate for rewrite/refactor, but there are other plugins using it as well. We will probably keep the idea and if we change the implementation, this could be then updated in all affected plugins the same way.

Regarding the cgroups, there is support for cgroups v1 in the scheduler plugin and we would also like to add support for the v2 for completeness. It could be useful for somebody.

It's OK if you are not using some plugin. We even wanted to add global configuration option allowing selective disablement of specific plugins in the stock profiles.

Regarding the cgroups, there is support for cgroups v1 in the scheduler plugin and we would also like to add support for the v2 for completeness. It could be useful for somebody.

I found the whole cgroup topic to be rather tricky, because in modern systems, SystemD is the "cgroup manager", and it owns (by convention) the cgroup tree. So any creation of new cgroups should happen via SystemD, and can then use Delegation to create further sub-groups.

I've had some success with:

• set AllowedCPUs on all the default slices (system.slice, user.slice, init.scope) to restrict all "normal" processes. This to some extent replaces the isolcpus= kernel option.
• Create an isolated.slice using SystemD, with access to the desired CPUs, and then use Slice=isolated in my service file (or systemd-run --slice=isolated when launching from a shell) to gain access to the isolated CPUs.

But simply having TuneD move processes around seems like it could have unwanted side-effects, and should be handled with care...

Update:

• rebased on latest main
• added check of perf events, according to finding by @zacikpa in scheduler: Do not assume that perf events have type attribute #691

@yarda did you already have a chance to review this PR?

Sorry for the delay, I am back on it.

The 5d28337 LGTM.

Regarding the kthread plugin is there a specific need for the proposed syntax:

group.ksoftirqd=0:f:2:*:^\[ksoftirqd

Wouldn't be better to use one group per instance? I.e. the same affinity/sched_opts setting for individual instance, e.g.:

[ksoftirqd]
type=kthread
devices_udev_regex=^\[ksoftirqd
setting=0:f:2:*

Or:

[ksoftirqd]
type=kthread
devices_udev_regex=^\[ksoftirqd
schedopts=SCHED_FIFO
affinity=*

Then for the priority the builtin instance priority option could be used. The affinity if unset could default to *.

You could also specify multiple regexes per instance:

[ksoftirqd_and_ksmd]
type=kthread
devices_udev_regex=^\[(ksoftirqd)|(ksmd)
schedopts=SCHED_FIFO

Wouldn't be better to use one group per instance? I.e. the same affinity/sched_opts setting for individual instance, e.g.:

I thought about this when I wrote the plugin, and didn't like it because

• I like the "default" of having only one instance per plugin in the profile, unless doing some specific optimizations. That instance has the name of the plugin, so type= is not needed. In the current profiles only few very specific cases need multiple instances (e.g. ThunderX).
• The approach with multiple instances would make the common case (what's currently used in the realtime profiles) much more complex to express.

I find the current format in the scheduler plugin quite clear, except for minor points I've changed:

• unify policy and priority into one option (f50 instead of f:50) because setting those separately makes no sense to me
• remove the braces [] from thread names (the scheduler plugin adds them to identify kernel threads, but here we have only kernel threads, so no need for this)

[ksoftirqd]
type=kthread
devices_udev_regex=^\[ksoftirqd
setting=0:f:2:*

Also re-using the existing devices_udev_regex is not very clean, as we're not dealing with udev Devices here. So the setting we're using in the profiles would be "wrong", and internally we'd need to create pyudev.Device objects just to use the existing mechanism.

Here in one instance there can be multiple "devices" with multiple different tuning. I don't like that it breaks the used logic concept that in each instance there are "devices" with the same tuning. I am afraid that it could lead to multiple problems later (e.g. when moving "devices" between instances through the API).

But maybe it's just my personal preference, @zacikpa, @jmencak what's your opinion?

I'm personally fine with the implementation as it is now (since it's inspired by the groups.* implementation in the scheduler plugin), but I would not refer to the kthreads as devices anywhere in the code/comments. In other words, the new plugin would not support "devices" in the TuneD sense, similarly to the scheduler plugin.

No device plugin, like e.g. the sysfs plugin, this may work.

No device plugin, like e.g. the sysfs plugin, this may work.

One of the main points of the new plugin is to allow dynamic changes of the tuning (through the instance_[create|destroy] dbus calls). That only works on device-plugins (based on hotplug.Plugin).

Huh, taking back what I said here, I say we should adjust instance_create and instance_destroy to work with any plugin, not just child classes of hotplug.Plugin.

IIUC, you can't and don't plan to use instance_acquire_devices with this plugin, am I right? (Because it does not support what TuneD calls "devices").

Huh, taking back what I said here, I say we should adjust instance_create and instance_destroy to work with any plugin, not just child classes of hotplug.Plugin.

The change itself is probably simple, but I'm not sure what would happen for any of the existing non-hotplug Plugins if multiple instances were created. I expect those instances would just interfere with each other and break things.

IIUC, you can't and don't plan to use instance_acquire_devices with this plugin, am I right? (Because it does not support what TuneD calls "devices").

instance_acquire_devices could be used, but it does not make much sense in this case. (One could force the transfer of a "device" to an instance that does not match it, but then no tuning would be applied).

Treating kthreads as "devices" lets me reuse a lot of nice infrastructure. But it would of course be possible to do this all within the plugin.

Huh, taking back what I said here, I say we should adjust instance_create and instance_destroy to work with any plugin, not just child classes of hotplug.Plugin.

The change itself is probably simple, but I'm not sure what would happen for any of the existing non-hotplug Plugins if multiple instances were created. I expect those instances would just interfere with each other and break things.

IIUC, you can't and don't plan to use instance_acquire_devices with this plugin, am I right? (Because it does not support what TuneD calls "devices").

instance_acquire_devices could be used, but it does not make much sense in this case. (One could force the transfer of a "device" to an instance that does not match it, but then no tuning would be applied).

Treating kthreads as "devices" lets me reuse a lot of nice infrastructure. But it would of course be possible to do this all within the plugin.

@zacikpa I just pushed a draft that bases the plugin on base.Plugin instead of hotplug.Plugin. The changes in controller.py probably need some more work.